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REMARKS 

For the reasons discussed during the interview and explained below, Applicants 
respectfully submit that the rejections of 1-21 are improper. 
I. Rejections based on four Mercury Interactive Patent References 

In the Office Action, the Examiner rejected Claims 1-21 based on four Mercury 
Interactive patent references. Specifically, the Examiner rejected Claims 1-21 : 

• on provisional obviousness-type double patenting grounds over Appl. No. 
10/057,295; 

• on provisional obviousness-type double patenting grounds over Appl. No. 
10/038,098; 

• on obviousness-type double patenting grounds over U.S. Pat. 6,738,933; and 

• on anticipation grounds over U.S. Pub. 2002/01 98985. 

Because these four Mercury Interactive patent references share a common specification 
(i.e., the technical disclosures of the specifications are substantially identical), Applicants will 
address these four bases for rejection together. 

As discussed during the telephone interview, the common specification of the four 
Mercury Interactive references discloses a monitoring system that includes various features for 
monitoring a transactional server. In contrast to the system described in the present application, 
these features do not make use of a probe that runs on an application server and measures the 
execution times of individual application components invoked as part of a transaction. See 
Claims 1 and 1 1 of the present application, discussed below. To assist the Examiner in better 
understanding this and other distinctions, three particular features described in the common 
specification are summarized below. 

Transaction Breakdown Feature 

One feature described in the common specification is a "transaction breakdown" feature. 
This feature is illustrated in Figures 23-25, and is described in section VIII- A ("Transaction 
Breakdown"). As discussed during the interview, the transaction breakdown feature enables a 
user of the monitoring system (e.g., a system administrator) to view a graphical breakdown which 
reveals how much of the total transaction time is attributable to, e.g., DNS resolution, connection 
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establishment, server time, network time, and client time. See Figures 23 and 24. Such a 
transaction breakdown report may, for example, reveal that a particular type of transaction has a 
longer than expected average transaction time, and that the delay is primarily attributable to the 
transactional server (as opposed, e.g., to the network). 

While this information may be helpful, it typically would not be sufficient for 
determining why the transactional server is performing poorly. For example, if multiple 
application components are invoked on an application server as part of this transaction, the 
transaction breakdown report would not reveal the execution times of these individual 
application components; thus, the administrator could not readily determine, e.g., whether a 
particular one of these application components is the main source of the delay. 

One of the four Mercury Interactive references, Appl. No. 10/038,098, includes claims 
that are directed to aspects of the transaction breakdown feature, and the Examiner relied on 
these claims to formulate a provisional obviousness-type double patenting rejection. The '098 
application was allowed on January 4, 2007 with an Examiner's Amendment to the claims. 
Server Resource Monitoring Feature 

The common specification also discloses a "server resource monitoring" feature. This 
feature is illustrated in Figures 26-30 and is described in section VIII-B ("Server Resource 
Monitoring"). 

As discussed during the interview, the server resource monitoring feature enables an 
administrator to assess whether performance problems have a correlation with particular server 
resource parameters. For example, using the graph shown in Figure 30, an administrator may 
identify that a correlation exists between transaction response times and the server resource 
parameter "server memory capacity." This information is useful for pinpointing certain types of 
problems such as those involving server resource deficiencies. 

As with the transaction breakdown feature, the server resource monitoring feature does 
not reveal the execution times of individual application components invoked as part of a 
transaction. Thus, for example, a problem resulting from a poorly written application component 
may not be readily identifiable using the server resource monitoring feature. 
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Root Cause Analysis Feature 

The common specification also discloses a Root Cause Analysis (RCA) feature. The 
RCA feature is illustrated in Figures 32-37 and is described in section VIII-D. 

As discussed during the interview, the Root Cause Analysis feature automatically detects 
correlations between particular performance parameters. For example, the RCA system may 
automatically detect that the transactional server is experiencing longer than usual response 
times, and that this performance problem is correlated with a particular server resource 
parameter, such as disk space. As with the transaction breakdown and server resource 
monitoring features discussed above, the RCA feature does not reveal the execution times of 
individual application components that are invoked as part of a transaction. 

Aspects of the Root Cause Analysis feature are claimed in two of the Mercury Interactive 
references, U.S. Pat. 6,738,933 and U.S. Appl. No. 10/057,295 (currently on appeal). The 
Examiner relied on these claims to formulate obviousness-type double patenting rejections. 
Discussion 

In view of the foregoing, Applicants submit that the common specification does not 
disclose at least the bolded limitations shown below in independent Claims 1 and 1 1 : 

1. A system for analyzing the operation of a web site system that 
comprises an application server, the system comprising: 

an agent computer configured to access the web site system as a 
emulated user thereof to execute a transaction that invokes the application 
server; 

a probe that runs on the application server and monitors the 
application server during execution of the transaction, wherein the probe 
generates and reports data indicative of execution times of each of a 
plurality of application components executed by the application server 
as part of the transaction; and 

a reports server that receives said data indicative of the execution 
times of each of the plurality of application components, and provides a 
breakdown indicating an amount of time spent by each of the 
plurality of application components executing the transaction. 
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11. A method for analyzing the operation of a web site system that 
comprises an application server, the method comprising: 

during execution of a user transaction that invokes an 
application on the application server, monitoring execution of the 
application with a probe that runs on the application server to 
measure execution times associated with each of a plurality of 
application components invoked by the user transaction, to thereby 
generate a set of transaction-specific time measurements; and 

incorporating the set of transaction-specific time measurements 
into a report that provides a transaction-specific breakdown of times 
spent by each of the plurality of application components during 
processing by the application server of the user transaction. 

Applicants also respectfully submit that the common specification does not disclose the 
feature described in the limitations bolded below in independent Claim 19: 

19. A system for monitoring application server performance of a 
deployed web site, the system comprising: 

a probe that runs on an application server of the web site, wherein 
the probe includes functionality for selectively monitoring the execution of 
transactions by the application server to collect application server 
performance data; and 

an agent component that runs on a host computer that resides 
externally to the deployed web site, wherein the agent component is 
configured to initiate execution of transactions by sending transaction 
requests to the web site; 

wherein the agent component specifies that a transaction is to 
be monitored by the probe by including encoded information within a 
corresponding transaction request sent to the web site, and wherein 
the probe is responsive to the encoded information by monitoring 
execution of the transaction to generate application server 
performance data for the transaction. 

As discussed during the interview, the portions of the common specification cited in the Office 
Action (including Figs. 1, 17, 20 and 25) simply do not disclose this feature. 

Because the bolded limitations of Claims 1,11 and 19 are not disclosed by the common 
specification, they cannot validly be included in the claims of Appl. Nos. 10/057,295 and 
10/038,098 and Patent No. 6,738,933. Indeed, these limitations do not appear in the claims of 
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any of these three references . Consequently, the provisional and non-provisional obviousness- 
type double patenting rejections of Claims 1-21 over these three references are improper. 

Further, because the bolded limitations are not disclosed in the common specification, the 
anticipation rejection over U.S. Pub. 2002/0198985 is improper. 

For the foregoing reasons, Applicants respectfully submit that the rejections over the four 
Mercury Interactive patent references are improper, and request that these rejections be 
withdrawn. 

As discussed during the telephone interview, the dependent claims recite additional 
distinctions over the four Mercury Interactive references. For instance, the Mercury Interactive 
references do not disclose or claim a probe that "includes a code instrumentation component that 
dynamically instruments the application components at load time" as recited in Claim 4. As 
another example, the Mercury Interactive references do not disclose or claim a user interface 
"that displays a listing of application components installed on the application server, and 
provides functionality for an operator to select specific application components from the listing 
to instrument for monitoring," as recited in Claim 6. 
II. Anticipation Rejection over Forman 

Claims 1-21 also stand rejected as anticipated by U.S. Pat. 6,178,449 to Forman. 
Applicants respectfully submit that this rejection is improper because Forman does not disclose 
the limitations of any independent claim. Each independent claim is discussed below. 

Independent Claim 1 

Regarding Claim 1, Applicants respectfully submit that the anticipation rejection is 
improper because Forman does not disclose the following: "wherein the probe generates and 
reports data indicative of execution times of each of a plurality of application components 
executed by the application server as part of the transaction." 

In connection with this claim language, the Examiner cites the abstract; Figs. 3, 4, 6 and 
7; and col. 5, lines 23-52 of Forman. Nothing in these or any other portion of Forman, however, 
discloses a probe or any other component that "generates and reports data indicative of execution 
times of each of a plurality of application components executed by the application server as part 
of the transaction." In this regard, the response times measured in Forman are apparently overall 
transaction response times seen by end users, and not "execution times of each of a plurality of 
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application components executed ... as part of the transaction." See Forman at col. 4, lines 44- 
46. Indeed, Forman does not disclose that a plurality of application components are executed as 
part of a transaction, let alone that the execution times of such application components are 
monitored. 

The rejection of Claim 1 is also improper because Forman does not disclose a reports 
server that "provides a breakdown indicating an amount of time spent by each of the plurality of 
application components executing the transaction." To the contrary, Forman' s system appears to 
report the overall response time of a transaction without regard to how much time may have been 
spent by each of a plurality of application components. As discussed during the interview, the 
notations CI, C2 ... C5 in Figure 6 of Forman do not represent execution times of individual 
application components. Rather, these notations represent response time thresholds that are used 
to maintain statistical data (count values) regarding response time measurements. See Forman at 
col. 8, last paragraph. 

Because Forman does not disclose all of the limitations of Claim 1, the rejection of Claim 
1 is improper. 

Independent Claim 1 1 

Regarding Claim 11, Applicants respectfully submit that the anticipation rejection is 
improper because Forman does not disclose "monitoring execution of the application with a 
probe that runs on the application server to measure execution times associated with each of a 
plurality of application components invoked by the user transaction, to thereby generate a set of 
transaction-specific time measurements." As discussed above, nowhere does Forman disclose 
that a plurality of application components are invoked by a transaction, let alone the measuring of 
execution times associated with each such application component. In this regard, the response 
time measurements in Forman are apparently overall transaction response times seen by end 
users. 

The rejection of Claim 11 is also improper because Forman does not disclose 
"incorporating the set of transaction-specific time measurements into a report that provides a 
transaction-specific breakdown of times spent by each of the plurality of application components 
during processing by the application server of the user transaction." The notations CI, C2 ... C5 
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do not represent such a breakdown. Indeed, Forman's system apparently would not be capable of 
providing a transaction-specific breakdown of the type described in the claim. 

Because Forman does not disclose all of the limitations of Claim 11, the rejection of 
Claim 1 1 is improper. 

Independent Claim 19 

Regarding Claim 19, Applicants respectfully submit that the anticipation rejection is 
improper because Forman does not disclose an agent component and probe that function as 
follows: "the agent component specifies that a transaction is to be monitored by the probe by 
including encoded information within a corresponding transaction request sent to the web site, 
and wherein the probe is responsive to the encoded information by monitoring execution of the 
transaction to generate application server performance data for the transaction." As discussed 
during the telephone interview, the transaction time agent 460 and transaction time manager 422 
of Forman do not operate in this manner. 

Dependent Claims 

The anticipation rejections of the dependent claims over Forman are improper in view of 
their respective dependencies from independent Claims 1,11 and 19. In addition, at least some 
of the dependent claims add limitations that are not disclosed by Forman. For example, Forman 
does not disclose a probe that "includes a code instrumentation component that dynamically 
instruments the application components at load time" as recited in Claim 4. As another example, 
Forman does not disclose or claim "a user interface that displays a listing of application 
components installed on the application server, and provides functionality for an operator to 
select specific application components from the listing to instrument for monitoring," as recited 
in Claim 6. 
III. Conclusion 

In view of the foregoing, Applicants respectfully submit that the rejections of Claims 1-21 
are improper, and request that these rejections be withdrawn. 
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If any issues remain which can potentially be resolved by telephone, the Examiner is 
invited to call the undersigned attorney of record at his direct dial number of 949-721-2950. 


Dated: / ~ Q "7 


Respectfully submitted, 

KNOBBE, MARTENS, OLSON & BEAR, LLP 


By: 



Registration No. 38,297 
Attorney of Record 
2040 Main Street 
Irvine, CA 92614 
949-721-2950 
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